Currently, a multicast receiver terminal wishing to receive a given multicast stream, for example delivered by a multicast server, registers in advance with a multicast group. This registration allows this terminal, or a multicast receiver address representing this latter, to be inserted into a multicast tree structure, to which all the members of the same multicast group belong. As a result of the multicast tree structure previously mentioned, formed by the connection of all its members to a network, all the members of a multicast group receive the same multicast transmission of information. This transmission can be defined as a point/multi-point transmission.
Also as a result of this type of transmission, the multicast transmissions are not acknowledged by the receiver terminals which receive them. In fact, if each receiver terminal had to acknowledge each packet of data that it received in a multicast stream, there would be a very large increase in the volume of data to be transmitted, and very often, a prohibitively heavy load on the network supports of such a transmission.
The absence of acknowledgement of the multicast type data received is not a problem in itself, when the physical transport link is very reliable. This is the case for example when the physical link is an Ethernet cable.
On the other hand, when the physical transport link is not reliable, for example for a wireless link, certain multicast applications have proved to be very sensitive to the loss of data packets. This is in particular the case of audio and/or video multicast applications, which can be seriously affected in this way and thus can see their service quality drop unacceptably.
To date, various solutions have been suggested to remedy a drawback of this kind.
These solutions essentially propose a multicast acknowledgement procedure by transmission of messages of acknowledgement at level 2 or level 3 of the OSI (Qpen System Interconnection) model. It will be recalled that the OSI model mentioned previously defines a framework for implementing network communications protocols comprising 7 levels, the bottom level, level 1, corresponding to the physical layer and the top level, level 7, to the application layer dedicated to the user. For a more precise definition of the OSI model, reference can easily be made to the internet site at http://www.webopedia.com/quick-ref/OSI-layers.asp.
Among the above mentioned solutions, Patent Application US 2005 002365 proposes to make the diffusion of multicast information more reliable for unreliable links, such the as a wireless link according to the IEEE 802.11 standard. The proposed system relates to the OSI model layer of level 2 but the method described requires the implementation of new modules for the acknowledgement of multicast frames, not only in the multicast transmitter but also in each multicast receiver terminal.
Patent Application US 2003 206549 also suggests a way of making the broadcast of multicast information more reliable for unreliable links, such as wireless links according to the IEEE 802.11 standard, the proposed system however concerning level 3 of the OSI model layer. The method described consists of establishing an additional channel between the multicast receiver terminal and the multicast server, by means of which the receiver terminal is capable of requesting multicast information which is expected but not received. The multicast server can then proceed with the multicast rebroadcast of the required information. The method described by this document clearly overloads the server and the receiver terminals, which by definition receive all the rebroadcast. Moreover, the reliability process introduced by level 3 of the OSI model introduces an additional delay on multicast frame loss detection. This system also requires the implementation of new modules in the multicast transmitter and in each receiver terminal.
Finally, techniques have been proposed with the aim of avoiding propagation of multicast data packets in GPRS and/or UMTS mobile telephony network nodes, by conversion of multicast packets into unicast packets. This operation is implemented by a network appliance denoted as GGSN containing embedded software executing IGMP proxy functions. This latter intercepts and interprets the IGMP messages and maintains a correspondence table between the IP addresses of the multicast receiver terminals and the IP addresses of the multicast groups with which these receiver-terminals are registered. When a packet intended for a multicast group reaches the GGSN, the IGMP proxy verifies in its table the existence of one or more terminals each designated by a destination unicast IP address and where this is affirmative, replaces the multicast destination IP address of the packet with the unicast IP address of each of the multicast receiver terminals.
A function of this kind described in recommendation 3GPP TS29.061 cannot be implemented easily, as the IGMP proxy function is a heavy consumer of processing resources. The suggested solution mentioned previously can therefore in no way be implemented in network appliances which are not equipped with a router function, such as access points or home gateways in bridged mode for example.